リファクタリングとは、既存のコードの内部構造を変更することであり、外部動作を変更することなくコードを再構築するための規律正しい手法です。その核心は、動作を維持する一連の小さな変換です。各変換（「リファクタリング」と呼ばれる）は小さな変更ですが、これらの変換のシーケンスは、大幅な再構築をもたらす可能性があります。各リファクタリングは小さいため、誤りが発生する可能性が低くなります。システムは各リファクタリングの後も完全に動作するため、再構築中にシステムが深刻な損傷を受ける可能性が低くなります。

ソフトウェア開発プロジェクトでは、ソフトウェアの品質向上に時間をかけるか、より価値のある機能のリリースに集中するかという議論が一般的です。通常、機能を提供するというプレッシャーが議論を支配し、多くの開発者は、アーキテクチャやコードの品質に取り組む時間がないと不満を言っています。この議論は、品質の向上によってコストも増加するという前提に基づいていますが、これは私たちの一般的な経験です。しかし、直感に反する現実として、内部的なソフトウェア品質は、新しい機能の開発を遅らせる無駄を排除し、ソフトウェアの機能強化のコストを削減します。

リファクタリングは広く知られた手法となり、ほとんどのソフトウェア開発チームは少なくとも定期的にリファクタリングを実施していると主張しています。しかし、多くのチームは、リファクタリングで使用できるさまざまなワークフローを理解しておらず、開発活動にリファクタリングを効果的に組み込む機会を逃しています。この資料では、さまざまなワークフローについて説明します。これにより、チームがリファクタリングをより深く作業に統合し、より適切に設計されたコードベースを実現し、新しい機能の追加を迅速かつ容易にすることを期待しています。

現代のWeb開発には多くの課題があり、その中でもセキュリティは非常に重要でありながら、しばしば軽視されています。脅威分析などの手法は、本格的な開発に不可欠であると認識されるようになってきていますが、すべての開発者が当然のこととして実行できる、そして実行すべき基本的な実践もあります。

ソフトウェアシステムにおけるオブザーバビリティは常に価値があり、クラウドとマイクロサービスの時代にはさらに重要になっています。しかし、システムに追加するオブザーバビリティは、低レベルで技術的な性質のものである傾向があり、多くの場合、コードベースにさまざまなログ、インストルメンテーション、分析フレームワークへの粗雑で冗長な呼び出しを散りばめる必要があるように見えます。この記事では、この混乱を解消し、クリーンでテスト可能な方法でビジネス関連のオブザーバビリティを追加できるパターンについて説明します。

外部サービスを扱うコードを作成する場合、アクセスコードを個別のオブジェクトに分離することが有効だと考えています。ここでは、凝集したコードをこの分離の一般的なパターンにリファクタリングする方法を示します。

多くの場合、システムをより柔軟にするために設計手法が使用されますが、作業が難しくなることがあります。その理由の1つは、明示性が設計においてしばしば忘れられるプロパティであることです。

面倒なデータ指向タスクからの苦痛を軽減するために、メタデータベースのアプローチを使用できます。

値に対して新しいユーザー定義型（またはクラス）を作成する際のガイドライン。

Kent Beckは、1990年代後半にエクストリームプログラミングを開発している間に、シンプルな設計の4つのルールを考案しました。私はそれらをこのように表現します。

コードの臭いとは、通常、システムのより深い問題に対応する表面的な兆候です。この用語は、私がリファクタリングの本に取り組んでいる際に、Kent Beckによって最初に造られました。

「コマンドクエリ分離」という用語は、Bertrand Meyerの著書「オブジェクト指向ソフトウェア構築」で造られました。これは、オブジェクト指向の初期において最も影響力のあるオブジェクト指向の本の1つです。（第1版が影響力を持っていました。第2版も良いですが、持ち上げるには数ヶ月ジムに通う必要があります。）

保守可能なコードを作成する上で最も強力なツールの1つは、大きなメソッドを名前の付けられた小さなメソッドに分割することです。これは、Kent Beckが合成メソッドパターンと呼んでいる手法です。

2つか3つの値がまとめて集まっているときは、それらを$%#$%^オブジェクトに変換します。

-- 私（声があった方がもっと面白かった）

これは、リファクタリングの本からの私のお気に入りのコードの臭いの1つです。同じいくつかのデータ項目が常に一緒に渡されている場合に見つかります。startとendは、範囲になりそうなデータの塊の良い例です。多くの場合、データの塊は、オブジェクトに変換しようと考える人がいないプリミティブな値です。

ソフトウェアをうまく設計する価値はあるのか？

（辞書に追加します。）

テスト不能（形容詞）：テストできないソフトウェア。

私のキャリアの中で、関数の適切な長さについて多くの議論を聞いてきました。これは、より重要な質問である「いつコードを独自の関数にカプセル化するべきか」に対する代理指標です。これらのガイドラインの一部は、長さに基づいていました（例：関数は画面に収まるサイズを超えてはならない）。その他は再利用に基づいていました（2回以上使用されるコードは独自の関数に配置する必要がありますが、1回しか使用されないコードはインラインのままにする必要があります）。しかし、私にとって最も意味のある議論は、意図と実装の分離です。コードの断片を見てそれが何をしているのかを理解するのに苦労する必要がある場合、それを関数に抽出し、その「何」にちなんで関数を命名する必要があります。そうすることで、再度読むときに、関数の目的がすぐに分かり、ほとんどの場合、関数がその目的をどのように果たしているか（つまり、関数の本体）を気にする必要がなくなります。

私の見解では、Gang of Fourは、オブジェクト指向設計について書かれた最高の書籍であり、おそらくあらゆるスタイルの設計の中でも最高の書籍です。この本はソフトウェア業界に非常に大きな影響を与えてきました。Javaや.NETライブラリにはGOFパターンが満載されているのを見れば分かります。

自己テストコードとは、私がリファクタリングの中で使用した名称で、機能的なソフトウェアと同時に包括的な自動テストを作成するという実践手法を指します。適切に実行すれば、単一のコマンドでテストを実行でき、コードに潜むバグを確実に明らかにすることができます。

ソフトウェアシステムは、クラフト（システムの変更と拡張を理想よりも困難にする内部品質の欠陥）の蓄積を起こしやすい傾向があります。技術的負債は、ウォード・カニンガムによって造られた比喩で、このクラフトに対処する方法を考えるための枠組みを提供します。金融上の負債のように考え、新しい機能を追加するのにかかる余分な労力は、負債に対する利息だと考えます。

テスト駆動開発（TDD）は、テストを書いてソフトウェア開発をガイドするソフトウェア構築手法です。1990年代後半にケント・ベックによってエクストリームプログラミングの一部として開発されました。本質的には、3つの簡単なステップを繰り返し実行します。

YAGNIはもともと「You Aren't Gonna Need It（必要になることはないだろう）」の頭字語です。エクストリームプログラミングのマントラであり、一般的にアジャイルソフトウェアチームで使用されます。これは、将来ソフトウェアが必要だと想定する機能を、"必要になることはないだろう"という理由で、今は構築すべきではないという主張です。